The present invention relates to cryptographic systems. In particular, the present invention relates to a key management system and a shared public cryptographic control unit.
Many computer applications need to perform one or more secure functions. A secure function of a computer program is a feature or operation of that computer program that is highly resistant to tampering by the user.
For example, a software program may have an expiration date after which the software program becomes inoperable. However, a typical software expiration function is not secure because it is easily defeated by resetting the local computer clock to an earlier time setting, or by modifying the software to jump over the portion of the program that checks the local computer clock.
As another example, a computer program that keeps a record of data accessed from a local encrypted database for the purpose of charging for the metered use of the local encrypted database typically has two critical registers. A first register represents the amount of past data usage, and another register represents the amount of remaining credit. However, if updating the usage and credit registers is not a secure function, the user could reduce the contents of the usage register and/or increase the contents of the credit register to defeat the system. Similarly, rented software that keeps a record of its own usage for rental charge purposes needs a secure function to prevent the user from tampering with the rental accounting registers, and other critical internal registers and functions.
As another example, a remote access database may charge authorized users for access to the database. A secure function is often needed to authenticate the identity of each user before granting access to the database. Yet another secure function is key management, i.e., the distribution of cryptographic keys to authorized users.
One class of secure function solutions is to implement secure functions in software. Implementing a secure function in software has the advantage of economy. Software implementations also have the advantage of being universal. However, implementing a software secure function in software is not as secure as implementing a secure function in hardware. On the other hand, hardware implementation of a secure function is more costly than software, and may require specialized hardware for each application. If each application requires its own specialized hardware, a hardware implementation of a secure function is not universal.
The present invention is embodied in a method and apparatus for using a cryptographic control unit as a universally available, public cryptographic control unit (crypto unit) in a system shared by multiple independent users.
The crypto unit contains a general-purpose computer processor having special purpose hardware and firmware to permit secure sharing of the crypto unit resources. In particular, the crypto unit includes a microprocessor core with a dedicated kernel of read only memory (ROM) control programming, a general purpose random access memory (RAM), a real time clock and a host input/output interface (i.e., to or from the desktop PC). In addition, the crypto unit includes a DES (Data Encryption Standard) engine, secure non-volatile storage for cryptographic keys, a signature registry RAM memory and special purpose access register.
The crypto unit is installed as a peripheral device into any general-purpose computer, such as a desktop PC. What makes the crypto unit a xe2x80x9cpublicxe2x80x9d cryptographic control unit, is that it is available to the main application program running on the PC as a secure computing resource.
In order to use the crypto unit resources, a portion of the main application program corresponding to the secure function is stored on the PC. The secure functions, which are called security applets herein, are loaded and unloaded into the onboard RAM of the crypto unit, where each security applet is run. By analogy to Java applets, which are downloaded and run inside browsers, a security applet is a portable, executable file intended to be loaded into a suitable computing entity and to perform one or more secure functions. In this sense, the crypto unit is like a special purpose coprocessor adapted for running security applications (applets).
The PC causes the security applet to be loaded into the program control memory of the crypto unit, which runs the applet and returns the result of the secure function to the PC. However, unlike a typical coprocessor, access to the crypto unit is not solely under the control of the desktop PC. That is, the desktop PC may not load and run just any security applet. The crypto unit and the system of which it is a part, provides its secure internal environment only some security applets are granted permission to load and run inside the crypto unit.
To secure the computing environment within the crypto unit, a cryptographic operations center (OPC) is provided which OPC communicates with the crypto unit. In particular, the crypto unit communicates with the OPC the first time a new security applet is encountered, and before the new security applet is allowed to run in the public crypto unit. The crypto unit also communicates with the OPC the first time a new crypto unit is installed on the desktop PC. The crypto unit also communicates with the OPC on a regular periodic basis. Furthermore, the software developer also communicates with the OPC, prior to distributing a given security applet for the purpose of obtaining the necessary permission for the given security applet to load and run in the crypto unit. Only if all necessary permissions are obtained from the OPC will a given security applet be allowed to load and run in the crypto unit.
The crypto unit operating system (O/S) consists of two parts: a RON loader control program, and a native mode security applet. The RON loader control program is a compact dedicated kernel of control programming which is stored in ROM in the crypto unit. The native mode security applet, which may be distributed by floppy disk, CDROM or telephone modem, is a portable and writable file typically stored in the hard drive of the desktop PC.
Critical security functions are implemented in the ROM loader control program. In particular, the ROM loader control program controls the loading and unloading of security applets to and from the crypto unit and external sources, including the loading and unloading of the native mode security applet.
The native mode security applet has two main functions: to register the crypto unit at the OPC upon first use of the crypto unit, and to grant permission for the first use of each individual application security applet. As a general rule, the native mode security applet is used whenever the crypto unit communicates with the OPC.
Application developers desiring to use the public cryptographic control unit in their secure software application must first submit a proposed security applet to the OPC for consideration. The proposed security applet must meet certain standards including security standards. For example, the proposed security applet must be small enough to fit into the onboard RAM on the crypto unit. The OPC further inspects the proposed security applet for compliance with security standards.
After all security compliance tests are completed, the OPC grants or denies permission for the proposed security applet to use the crypto unit. Permission to use a proposed security applet consists of assigning a serial number and a cryptographic code key C to the approved security applet. The serial number and code key C are stored in an applet registry in the OPC. The developer uses the code key C in a process to encrypt the approved security applet, and uses the serial number to identify the encrypted security applet.
Upon start up initialization of the desktop PC, the crypto unit RON loader control program loads the native mode security applet into onboard RAM in the crypto unit. The ROM loader control program treats the native mode security applet as though it has been previously granted permission from the OPC to load and run in the crypto unit.
The ROM loader control program facilitates the shared use of the crypto unit among multiple users. in particular, the ROM loader control program unloads (swaps out) the native mode security applet from onboard RAM in the crypto unit into the hard drive of the desktop PC to make room for loading (swaps in) a first application security applet into the onboard RAM.
The ROM loader control program then inspects the first application security applet while it is loading. After determining that the loaded first application security applet is entitled to access to the crypto unit resources, the microprocessor in the crypto unit runs the first security applet, thus turning over control of the crypto unit to the first security applet.
When the first security applet is done, the crypto unit unloads (swaps out) the presently loaded first security applet in encrypted form to the PC hard drive, and loads (swaps in) the next security applet. The cryptographic context of each security applet is preserved in the file stored on the PC hard drive. In such manner, a single crypto unit is shared among a plurality of independent users.
If an unknown application security applet is encountered (i.e., a security applet that has never been loaded into this particular crypto unit), the ROM loader control program swaps back in the native mode security applet, which establishes a secure communication session with the OPC. If the software developer who wrote the unknown application security applet has been previously granted permission by the OPC to load and run that security applet, then the crypto unit will receive from the OPC the cryptographic keys needed to decrypt and run the unknown application security applet. At the same time, the OPC records the crypto unit user identification in the applet registry, thereby associating the crypto unit with the security applet for which the OPC has granted permission to load and run. Thereafter, the crypto unit will load and unload the security applet without further communication with the OPC.
Finally, when no application security applet is running, the ROM loader control program swaps in the native mode security applet back into the onboard RAM in the crypto unit. In such manner, each independent user uses the crypto unit for a respective separate secure application. Thus, a plurality of independent users, using a plurality of independent secure applications shares the crypto unit.